Hey! First of all, thank you so much for contributing. I've been wanting to add Tautulli for a while but just haven't had the time to tackle it myself.

I took a quick look at your code, and it looks really solid! I was initially concerned about stuff like caching being forgotten, but it seems like you've got that covered.

I do have a few questions, but I'd like to test things out a bit more on my end before raising them as potential issues. Mainly these:

• In tautulli-api.service.ts, I noticed you're throwing some errors. From my experience, throwing errors can crash the Nest process, which is why I generally avoid it. I'd like to test this behavior to ensure it doesn't cause issues. If the server remains stable, then throwing errors should be fine.

• In rules.constants.ts, you're reusing some rule names. I can't confirm right now, but I believe these need to be unique for the YAML export/import functionality to work correctly, as the names are used as identifiers.

Thanks again for your work! Looking forward to getting this merged!

Edit: Oh, and the proposed changes to settings.json & the formatter are fine for me. I haven't really looked at them for a long time, i'm sure there are improvements that can be made in that regard.

Thank you for the feedback!

* In [tautulli-api.service.ts](https://github.com/jorenn92/Maintainerr/pull/1280/files#diff-d5286827f45e77815c8398f8acc4c0fad3f8e009e51e988a7eae1434fb0a9821), I noticed you're throwing some errors. From my experience, throwing errors can crash the Nest process, which is why I generally avoid it. I'd like to test this behavior to ensure it doesn't cause issues. If the server remains stable, then throwing errors should be fine.

These are thrown inside the try so they'll be caught a few lines below, unless Nest is doing something extremely bizarre 😆

* In [rules.constants.ts](https://github.com/jorenn92/Maintainerr/pull/1280/files#diff-9805460bc59579ece2e85a139616e5784e348c58a0e62b21fccd8f4cbc3e5f52), you're reusing some rule names. I can't confirm right now, but I believe these need to be unique for the YAML export/import functionality to work correctly, as the names are used as identifiers.

Ah right good to know. I'll test this later and see if I can add a TypeScript guard in to prevent dupes if that turns out to be the case.

EDIT:
This looks okay. The export prepends the application name:

If you need any testing done let me know. I am currently on the Dev version that is through dockerhub via Container Station (jorenn92/maintainerr).

If you need any testing done let me know. I am currently on the Dev version that is through dockerhub via Container Station (jorenn92/maintainerr).

That would be good! @jorenn92 I can rebase & squash my commits down to get this ready for a merge if you're happy? I can write some docs for this too, how are they populated?

This looks okay. The export prepends the application name:

Yep, you're right. This is a non issue. I should've checked before bringing this up.
It's also working well with community rules.

These are thrown inside the try so they'll be caught a few lines below, unless Nest is doing something extremely bizarre 😆

Yes, they should be fine. It's possible this issue was specific to earlier versions of Nest. We'll merge it with the error messages as they are. If testing reveals that the server does crash, we can adjust them later.

I tested your branch locally, and everything seems to be working well. Once you've rebased, I'm okay with merging and letting users of the dev image test it further.

The documentation is housed in a different project. You can push a PR to https://github.com/ydkmlt84/Maintainerr_docs, so @ydkmlt84 can merge it.

Thanks again for the great work!

First wanted to say great work guys! this Tautulli integration I think is something that will help a lot of people. :)

@jorenn92 I see the new tautulli option now in the settings and I had no issues getting that connection setup.
@benscobie So looking at the rules Tautulli options I see currently there is only the 1 regarding "[list] viewed by (user)". Any chance of adding a few more options to this (see highlighted in screenshot). With Plex being so inaccurate now with watched history, having the Tuatulli options for 'Date Added', 'Times Viewed', and 'Last view date' would be perfect to make this integration perfect for getting around the plex downfalls.

\

Example from Tautulli -> Libraries -> Library Name -> Media Info (not sure where in the api this is exactly), but this would give all 3 of the additional items info:

I actually was able to find the API for the total plays:
https://github.com/Tautulli/Tautulli/wiki/Tautulli-API-Reference#get_item_watch_time_stats

@gold007eye Thank you for the feedback, I'll have a look at an implementation of those rules later today.

@gold007eye For the Last view date, were you thinking that this would be the last time somebody fully watched (according to Tautulli) the content? This would align with Plex in a way. I was thinking as Tautulli returns all history there's the possibility of another rule where it's the last time somebody watched the content no matter how long for.

Yeah I think, personally, that it's important to use Tautulli for the things Plex doesn't do or doesn't do what we think is correctly. No need in making two of the same things and having people ask more questions I have to answer. It should be clear what the differences are between the two options and when to use one or the other.

New PR over here which adds the remaining Plex rules that relate to dates & watch percentage to Tautulli.

@gold007eye For the Last view date, were you thinking that this would be the last time somebody fully watched (according to Tautulli) the content? This would align with Plex in a way. I was thinking as Tautulli returns all history there's the possibility of another rule where it's the last time somebody watched the content no matter how long for.

@benscobie I think an option either way would be good.. I could see use cases both ways where the user could select that as the rule. Example here: I would actually personally have a rule consider that this was actually last viewed on 08-29-2024 vs going be the full 100% which would say this was last viewed 5-20-2023 over a year prior.

Yeah I think, personally, that it's important to use Tautulli for the things Plex doesn't do or doesn't do what we think is correctly. No need in making two of the same things and having people ask more questions I have to answer. It should be clear what the differences are between the two options and when to use one or the other.

I agree with this.. Plex and it's changes to what it thinks users wants leaves big holes in things.. My perfect example. Years ago I had setup folders for "movies - franchise" as Movies - Franchise --> Franchise Name -- MovieName.ext this worked fine for plex, but recently I decided to remove that extra folder layer and leave all movies in the main folder (this wiped out ALL history per Plex for these (even though I followed their move guide to a T)), so now Tautulli is really the only true source of real history.. and I have history going back to 2016 lol

@benscobie I think an option either way would be good.. I could see use cases both ways where the user could select that as the rule. Example here: I would actually personally have a rule consider that this was actually last viewed on 08-29-2024 vs going be the full 100% which would say this was last viewed 5-20-2023 over a year prior.

@gold007eye If you hover over the percentage complete on that 08-29-2024 history item what does it say? I'm just wondering how close it is to your current watched percentage setting in Tautulli as they've got it at 75% complete currently (Tautulli split it up into 0/25/50/75/100 chunks in their API field watched_status, but they also have the exact percentage complete in percent_complete). The way I did the new rule logic it'll still consider 5-20-2023 the last viewed as it's not reached the watched percent that's configured yet. With the other rule I mentioned that we could create, I've got two trains of thought:

1. Another set of rules which essentially do the same thing, but instead of 100% watch percentage (according to Tautulli) it's just anything. This might make the rules dropdown a bit messy though, and might cause some extra confusion as @ydkmlt84 mentioned...
2. Use the same rules that I've just added but in the General section of the rule you have the option to specify a Tautulli watch percentage to reach. This would serve as an override to the watched percentage setting of Tautulli on a whole rule basis.

The panacea solution I originally thought about was being able set the percentage watched within the individual rules so you get a lot of flexibility, but the rules engine isn't setup for that currently. I'm thinking option number 2 would serve most use cases though and also be quite tidy from a user point of view? But technically speaking it is a workaround to a rules limitation and might not be the best implementation. Interested to here your thoughts here too @ydkmlt84 @jorenn92

@benscobie I think an option either way would be good.. I could see use cases both ways where the user could select that as the rule. Example here: I would actually personally have a rule consider that this was actually last viewed on 08-29-2024 vs going be the full 100% which would say this was last viewed 5-20-2023 over a year prior.

@gold007eye If you hover over the percentage complete on that 08-29-2024 history item what does it say? I'm just wondering how close it is to your current watched percentage setting in Tautulli as they've got it at 75% complete currently (Tautulli split it up into 0/25/50/75/100 chunks in their API field watched_status, but they also have the exact percentage complete in percent_complete). The way I did the new rule logic it'll still consider 5-20-2023 the last viewed as it's not reached the watched percent that's configured yet. With the other rule I mentioned that we could create, I've got two trains of thought:

1. Another set of rules which essentially do the same thing, but instead of 100% watch percentage (according to Tautulli) it's just anything. This might make the rules dropdown a bit messy though, and might cause some extra confusion as @ydkmlt84 mentioned...

2. Use the same rules that I've just added but in the General section of the rule you have the option to specify a Tautulli watch percentage to reach. This would serve as an override to the watched percentage setting of Tautulli on a whole rule basis.

The panacea solution I originally thought about was being able set the percentage watched within the individual rules so you get a lot of flexibility, but the rules engine isn't setup for that currently. I'm thinking option number 2 would serve most use cases though and also be quite tidy from a user point of view? But technically speaking it is a workaround to a rules limitation and might not be the best implementation. Interested to here your thoughts here too @ydkmlt84 @jorenn92

I'm not entirely happy with the current state of the rule engine. It's still in the same form as when I first developed it, originally intended as a simple app for my personal use with only a handful of rules. I'd love to rewrite it into something more dynamic and flexible. A few days ago, I mentioned to @ydkmlt84 that I’d really like to add an 'addon' functionality. The idea is that users could simply drop zip files containing rules into a directory, and the system would load them. This way, anyone could add or modify rules without them being tied to the main repo or specific app versions.

Of course, we could still provide some 'curated' battle-tested rules by default, but this approach would also allow users to integrate custom rules from others if they wish.

That said, such a rewrite would be a significant change and is far outside the scope of this feature request. I just wanted to clarify that the rule engine doesn't have to remain in its current state forever.

In my opinion, the best option, though the most work, would be to make it configurable within the rule itself. For example, we could add an extra UI field that appears when selecting a rule, similar to how custom values are handled now. However, as you pointed out, this would require changes to the rule engine, UI, YAML export/import, and community rule mechanisms.

This might end up being too much work for the benefit it offers. I'm not sure how many users really need the ability to create two rules within the same ruleset based on different watch percentage statuses. If we go with option two, adding it as a general option, users can still create a second rule with a different percentage.

TL;DR: While making the rule itself configurable is the best approach in my opinion, I don't think it's worth the effort for this particular case. Users can still work around the limitation by creating another rule with a different percentage when this becomes a general option.

Appreciate the response, a rules rewrite sounds fun 😄 I'll have a look at making it a general option for now.

Appreciate the response, a rules rewrite sounds fun 😄 I'll have a look at making it a general option for now.

Well, I probably won't have the time for it anytime soon, so who knows if it'll ever happen.

By the way, in #1289 I altered the API command where the version info is fetched from. It was showing the Plex version before, because it fetched the Plex server info.

@benscobie I think an option either way would be good.. I could see use cases both ways where the user could select that as the rule. Example here: I would actually personally have a rule consider that this was actually last viewed on 08-29-2024 vs going be the full 100% which would say this was last viewed 5-20-2023 over a year prior.

@gold007eye If you hover over the percentage complete on that 08-29-2024 history item what does it say? I'm just wondering how close it is to your current watched percentage setting in Tautulli as they've got it at 75% complete currently (Tautulli split it up into 0/25/50/75/100 chunks in their API field watched_status, but they also have the exact percentage complete in percent_complete). The way I did the new rule logic it'll still consider 5-20-2023 the last viewed as it's not reached the watched percent that's configured yet. With the other rule I mentioned that we could create, I've got two trains of thought:

1. Another set of rules which essentially do the same thing, but instead of 100% watch percentage (according to Tautulli) it's just anything. This might make the rules dropdown a bit messy though, and might cause some extra confusion as @ydkmlt84 mentioned...

2. Use the same rules that I've just added but in the General section of the rule you have the option to specify a Tautulli watch percentage to reach. This would serve as an override to the watched percentage setting of Tautulli on a whole rule basis.

The panacea solution I originally thought about was being able set the percentage watched within the individual rules so you get a lot of flexibility, but the rules engine isn't setup for that currently. I'm thinking option number 2 would serve most use cases though and also be quite tidy from a user point of view? But technically speaking it is a workaround to a rules limitation and might not be the best implementation. Interested to here your thoughts here too @ydkmlt84 @jorenn92

@benscobie it is showing 72% complete. My guess is the last bit left is the credits. For my server I have the watched setting at 85% for movies and 90% for tv shows. This was just by me making adjustments to what overall worked for the past 10 years.

As for the 2 options, I think that option 2 would work from a user perspective if you are able to either

1. Leave blank and it defaults to tautulli configured watched %
2. User defined watch percentage as a numerical value e.g. (75) would = 75%

all around these are going to be GREAT improvements in giving better accuracy in what the rules will pull in.

@benscobie I think an option either way would be good.. I could see use cases both ways where the user could select that as the rule. Example here: I would actually personally have a rule consider that this was actually last viewed on 08-29-2024 vs going be the full 100% which would say this was last viewed 5-20-2023 over a year prior.

@gold007eye If you hover over the percentage complete on that 08-29-2024 history item what does it say? I'm just wondering how close it is to your current watched percentage setting in Tautulli as they've got it at 75% complete currently (Tautulli split it up into 0/25/50/75/100 chunks in their API field watched_status, but they also have the exact percentage complete in percent_complete). The way I did the new rule logic it'll still consider 5-20-2023 the last viewed as it's not reached the watched percent that's configured yet. With the other rule I mentioned that we could create, I've got two trains of thought:

1. Another set of rules which essentially do the same thing, but instead of 100% watch percentage (according to Tautulli) it's just anything. This might make the rules dropdown a bit messy though, and might cause some extra confusion as @ydkmlt84 mentioned...

2. Use the same rules that I've just added but in the General section of the rule you have the option to specify a Tautulli watch percentage to reach. This would serve as an override to the watched percentage setting of Tautulli on a whole rule basis.

The panacea solution I originally thought about was being able set the percentage watched within the individual rules so you get a lot of flexibility, but the rules engine isn't setup for that currently. I'm thinking option number 2 would serve most use cases though and also be quite tidy from a user point of view? But technically speaking it is a workaround to a rules limitation and might not be the best implementation. Interested to here your thoughts here too @ydkmlt84 @jorenn92

I'm not entirely happy with the current state of the rule engine. It's still in the same form as when I first developed it, originally intended as a simple app for my personal use with only a handful of rules. I'd love to rewrite it into something more dynamic and flexible. A few days ago, I mentioned to @ydkmlt84 that I’d really like to add an 'addon' functionality. The idea is that users could simply drop zip files containing rules into a directory, and the system would load them. This way, anyone could add or modify rules without them being tied to the main repo or specific app versions.

Of course, we could still provide some 'curated' battle-tested rules by default, but this approach would also allow users to integrate custom rules from others if they wish.

That said, such a rewrite would be a significant change and is far outside the scope of this feature request. I just wanted to clarify that the rule engine doesn't have to remain in its current state forever.

In my opinion, the best option, though the most work, would be to make it configurable within the rule itself. For example, we could add an extra UI field that appears when selecting a rule, similar to how custom values are handled now. However, as you pointed out, this would require changes to the rule engine, UI, YAML export/import, and community rule mechanisms.

This might end up being too much work for the benefit it offers. I'm not sure how many users really need the ability to create two rules within the same ruleset based on different watch percentage statuses. If we go with option two, adding it as a general option, users can still create a second rule with a different percentage.

TL;DR: While making the rule itself configurable is the best approach in my opinion, I don't think it's worth the effort for this particular case. Users can still work around the limitation by creating another rule with a different percentage when this becomes a general option.

On a side not of this. I would totally help coding if I had any clue on doing the coding.. lol. my career path has changed in the past decade so the last coding I worked on was visual basic. lol.

I know this is a bit off topic, but I love the ability to export the "rules yaml" I think an improvement on that would be the ability to export the entire rule itself (e.g Title, Description, etc. more so for either 1) My entire setup is hosed and recreating everything would be very simple and/or 2) If I am doing testing sometimes it would be easier to just be able to duplicate an existing rule and change variables to see different outcome (for the sake of this topic. Taking a current rule that is based on Plex info and duplicate that with only needing to change the options from "plex" to Tautulli.

@benscobie after doing some testing so far things are looking pretty good. All I needed to do was change plex. to tautulli. in the yaml and import.

I think your watched % idea is definitely going to come in handy with the new integration. So far this is all looking great and MUCH appreciated!

Here is a good example of where that will help get things a little more accurate.

• Context: Basically I have it that even if it is something older, if it has been viewed fully at least 10 times then it is something that will stay on there as it is popular.

Current Plex code view times = 7 (as it is only calculating fully watched)
- id: 0 result: true ruleResults: - operator: OR action: before firstValueName: Plex - Last view date firstValue: 2020-11-20T20:01:14.000Z secondValueName: custom_days secondValue: 2023-09-28T14:57:54.344Z result: true - operator: AND action: smaller firstValueName: Plex - Times viewed firstValue: 7 secondValueName: number secondValue: 10 result: true

New Tautulli code view times = 11 (as it is looking at total plays watch/partially watched) so being able to add that AND watched.percent = 85 statement after this would then pull it back in line to exclude something that someone watched for just a little bit and abandoned it. lol
- id: 0 result: false ruleResults: - operator: OR action: before firstValueName: Tautulli - Last view date firstValue: 2020-11-20T22:54:44.000Z secondValueName: custom_days secondValue: 2023-09-28T14:57:28.966Z result: true - operator: AND action: smaller firstValueName: Tautulli - Times viewed firstValue: 11 secondValueName: number secondValue: 10 result: false

To add to this another example where that % watched getting added will be helpful with this.

So this movie is looking at Tautulli times viewed as 2 based on api pull, but the actual % watched for these 2 views was 2% & 4% respectively so realistically you wouldn't want to count these as actual views because obviously this must have been a crappy movie :D

- id: 1 result: false operator: OR ruleResults: - operator: OR action: before firstValueName: Tautulli - Date added firstValue: 2022-01-31T21:52:50.000Z secondValueName: custom_days secondValue: 2023-09-28T16:43:48.044Z result: true - operator: AND action: equals firstValueName: Tautulli - Times viewed firstValue: 2 secondValueName: number secondValue: 0 result: false

To add to this another example where that % watched getting added will be helpful with this.

So this movie is looking at Tautulli times viewed as 2 based on api pull, but the actual % watched for these 2 views was 2% & 4% respectively so realistically you wouldn't want to count these as actual views because obviously this must have been a crappy movie :D

- id: 1 result: false operator: OR ruleResults: - operator: OR action: before firstValueName: Tautulli - Date added firstValue: 2022-01-31T21:52:50.000Z secondValueName: custom_days secondValue: 2023-09-28T16:43:48.044Z result: true - operator: AND action: equals firstValueName: Tautulli - Times viewed firstValue: 2 secondValueName: number secondValue: 0 result: false

Oh strange, that's not what I intended. It should only be returning views if they're over the Tautulli percent watched setting, which should also apply to all of the other rules I added 🤔

To add to this another example where that % watched getting added will be helpful with this.
So this movie is looking at Tautulli times viewed as 2 based on api pull, but the actual % watched for these 2 views was 2% & 4% respectively so realistically you wouldn't want to count these as actual views because obviously this must have been a crappy movie :D
- id: 1 result: false operator: OR ruleResults: - operator: OR action: before firstValueName: Tautulli - Date added firstValue: 2022-01-31T21:52:50.000Z secondValueName: custom_days secondValue: 2023-09-28T16:43:48.044Z result: true - operator: AND action: equals firstValueName: Tautulli - Times viewed firstValue: 2 secondValueName: number secondValue: 0 result: false

Oh strange, that's not what I intended. It should only be returning views if they're over the Tautulli percent watched setting, which should also apply to all of the other rules I added 🤔

Maybe that portion of the code is broke? It looks like it's taking the total plays regardless of whatever you have coded in the background.

Should there be a rule option like "Tautulli - Percent Complete" or are you currently doing this in the back-end code?

To add to this another example where that % watched getting added will be helpful with this.
So this movie is looking at Tautulli times viewed as 2 based on api pull, but the actual % watched for these 2 views was 2% & 4% respectively so realistically you wouldn't want to count these as actual views because obviously this must have been a crappy movie :D
- id: 1 result: false operator: OR ruleResults: - operator: OR action: before firstValueName: Tautulli - Date added firstValue: 2022-01-31T21:52:50.000Z secondValueName: custom_days secondValue: 2023-09-28T16:43:48.044Z result: true - operator: AND action: equals firstValueName: Tautulli - Times viewed firstValue: 2 secondValueName: number secondValue: 0 result: false

Oh strange, that's not what I intended. It should only be returning views if they're over the Tautulli percent watched setting, which should also apply to all of the other rules I added 🤔

Maybe that portion of the code is broke? It looks like it's taking the total plays regardless of whatever you have coded in the background.

Should there be a rule option like "Tautulli - Percent Complete" or are you currently doing this in the back-end code?

I was using get_item_watch_time_stats for this but that appears to return all views, I obviously didn't test that very well! PR up here to fix that: #1290

My intention is to add an option like this in the General section of a ruleset to allow overriding the watched percent configured in Tautulli:

I think that option would definitely be beneficial in the ruleset. So far things are looking good though over all. With coding there will always be tweaks and bugs hear and there lol

🎉 This PR is included in version 2.2.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀